1. Field of the Invention
The present invention relates generally to data interchange technology, and more particularly, though not exclusively, to a method and apparatus for inputting tagged or un-tagged data into electronic documents (e-forms), summing up data in the electronic document, or in a linked and separate document or file as one or more 1D and/or 2D bar codes ready for use in data interchange.
2. Problems in the Art
Electronic Data Interchange (EDI) is used throughout this document in the broadest sense as a method for capturing and interchanging information. Unless specifically referred to as one of the four following predominant narrowly defined EDI standards: 1) the United Nations recommended UN/EDIFACT is the only international standard and is predominant outside of North America, 2) the U.S. standard ANSI ASC X12 (X12) is predominant in North America, 3) the TRADACOMS standard developed by the ANA (Article Numbering Association) is predominant in the UK retail industry, and 4) The ODETTE standard used within the European automotive industry.
These narrowly defined EDI standards prescribe the formats, character sets, and data elements used in the exchange of business documents and forms. The complete X12 Document List includes all major business documents, including purchase orders (called “ORDERS” in UN/EDIFACT and an “850” in X12) and invoices (called “INVOIC” in UN/EDIFACT and an “810” in X12).
The narrowly defined EDI standards say which pieces of information are mandatory for a particular document, which pieces are optional and give the rules for the structure of the document. The standards are like building codes. Just as two kitchens can be built “to code” but look completely different, two EDI documents can follow the same standard and contain different sets of information. For example a food company may indicate a product's expiration date while a clothing manufacturer would choose to send color and size information.
Organizations that send or receive narrowly defined EDI documents from each other are referred to as “trading partners” in EDI terminology. The trading partners agree on the specific information to be transmitted and how it should be used. This is done in human readable specifications (also called Message Implementation Guidelines). While the standards are analogous to building codes, the specifications are analogous to blue prints. (The specification may also be called a mapping but the term mapping is typically reserved for specific machine readable instructions given to the translation software.) Larger trading “hubs” have existing Message Implementation Guidelines which mirror their business processes for processing EDI and they are usually unwilling to modify their EDI business practices to meet the needs of their trading partners. Often in a large company these narrowly defined EDI guidelines will be written to be generic enough to be used by different branches or divisions and therefore will contain information not needed for a particular business document exchange. For other large companies, they may create separate EDI guidelines for each branch/division.
Trading partners who use narrowly defined EDI are free to use any method for the transmission of documents. In the past one of the more popular methods was the usage of a bisync modem to communicate through a “Value Added Network” (VAN). Some organizations have used direct modem to modem connections, “Bulletin Board System” (BBS), and recently there has been a move towards using the some of the many Internet protocols for transmission, but most EDI is still transmitted using a VAN. In the healthcare industry, a VAN is referred to as a “Clearinghouse”.
In the most basic form, a VAN acts as a regional post office. They receive transactions, examine the ‘From’ and the ‘To’ information, and route the transaction to the final recipient. VAN's provide a number of additional services, e.g. retransmission of documents, provide third party audit information, and act as a gateway for different transmission methods, handling telecommunications support, etc. Because of these and other services VAN's provide, businesses frequently use a VAN even when both trading partners are using Internet-based protocols. Healthcare clearinghouses perform many of the same functions as a VAN, but have additional legal restrictions that govern protected healthcare information.
VAN's also provide an advantage with certificate replacement in AS2 transmissions. Because each node in a traditionally business-related AS2 transmission usually involves a security certificate, routing a large number of partners through a VAN can make certificate replacement much easier.
Until recently the Internet transmission was handled by nonstandard methods between trading partners usually involving FTP or email attachments. There are also standards for embedding EDI documents into XML. Many organizations are migrating to this protocol to reduce costs. For example, Wal-Mart is now requiring its trading partners to switch to the AS2 protocol.
Often missing from the narrowly defined EDI specifications (referred to as EDI Implementation Guidelines) are real world descriptions of how the information should be interpreted by the business receiving it. For example, suppose candy is packaged in a large box that contains 5 display boxes and each display box contains 24 boxes of candy packaged for the consumer. If an EDI document says to ship 10 boxes of candy it may not be clear whether to ship 10 consumer packaged boxes, 240 consumer packaged boxes or 1200 consumer packaged boxes. It is not enough for two parties to agree to use a particular qualifier indicating case, pack, box or each; they must also agree on what that particular qualifier means.
Translation software for narrowly defined EDI provides the interface between internal systems and the EDI format sent/received. For an “inbound” document the EDI solution will receive the file (either via a Value Added Network or directly using protocols such as FTP or AS2), take the received EDI file (commonly referred to as a “mailbag”), validate that the trading partner who is sending the file is a valid trading partner, that the structure of the file meets the narrowly defined EDI standards and that the individual fields of information conforms to the agreed upon standards. Typically the translator will either create a file of either fixed length, variable length or XML tagged format or “print” the received EDI document (for non-integrated EDI environments). The next step is to convert/transform the file that the translator creates into a format that can be imported into a company's back-end business systems or ERP. This can be accomplished by using a custom program, an integrated proprietary “mapper” or to use an integrated standards based graphical “mapper” using a standard data transformation language such as XSLT. The final step is to import the transformed file (or database) into the company's back-end ERP. It is important to note from the previous discussion, EDI is not XML. Narrowly defined EDI can be translated into an XML document, or XML can encapsulate EDI documents created using a standard such as, but not limited to, X12, UN/EDIFACT, TRADACOMS, ODETTE, etc.
To further highlight the difference between EDI in its narrow sense and XML, the following is about the current state of EDIFACT from a Wikipedia article on EDIFACT: “It seems there is a battle between XML and EDIFACT. An equivalent EDIFACT message will be smaller in size than an XML message but the XML message will be easier to read for a human (which is correct but of course not necessary because the content of such messages are not developed to be read by human but by computers). Another possible explanation is that compatibility is being favored over performance, since more tools exist to work with XML data than with EDIFACT. As mentioned in the beginning, EDIFACT-messages are smaller, in some cases about ten times smaller than XML-messages, and therefore not recommended for large message contents. The advantage of EDIFACT is the availability of agreed message-contents and the XML-world today needs these contents to develop similar “agreed” contents for XML.
One of the emerging XML standards is RosettaNet, widely used in the semiconductor and high tech industry in general. Another is UBL, currently being adopted by Scandinavian governments as legal requirement to send invoices to governments. For example, all invoices to the Danish government have had to be in electronic format since February 2005.
Another XML standard (also built by UN/CEFACT, like EDIFACT) is ebXML, often seen as a standard best suited for small and medium enterprises.
However, EDIFACT is still widely used in the high tech, civil aviation, retail and tourism industries and is likely to remain so for some time due to the amount of software making use of it and the need for newer systems to be able to integrate with legacy systems. Europe started early with adopting EDIFACT and therefore has a large installed base, where as for example the Asian region started later with B2B implementations and is therefore using more XML standards. As mentioned EDIFACT is widely used in Europe in nearly all areas of economy and the application will grow in future. One example is the energy market where the EDIFACT-Standard in Europe is a requirement for now and the future.” The point again is, EDI in its narrowly defined sense, such as, but not limited to, X12,UN/EDIFACT<TRADACOMS, ODETTE, etc. is XML is not EDI.
The following comes from the home page of the ASC X12 organization, a promulgator of narrowly defined, traditional EDI standards: “With more than 315 X12 EDI transactions, a growing collection of X12 XML schemas and related documents for national and global arenas, ASC X12 enhances data exchange processes from anywhere in your organization to anywhere in the world. Network and collaborate with business process experts, technology innovators, and complementary standards and industry initiatives to advance convergence, interoperability and message reusability across vertical and horizontal markets.” Again, the point is, one of the promulgators of a narrowly defined EDI, X12, says that they develop both EDI and XML standards for data interchange.
For an “outbound” document the process for integrated narrowly defined EDI is to export a file (or read a database) from a company's back-end ERP, transform the file to the appropriate format for the translator. The translation software will then “validate” the EDI file sent to ensure that it meets the standard agreed upon by the trading partners, convert the file into “EDI” format (adding in the appropriate identifiers and control structures) and send the file to the trading partner (using the appropriate communications protocol).
Another critical component of any narrowly defined EDI translation software is a complete “audit” of all the steps to move business documents between trading partners. The audit ensures that any transaction (which in reality is a business document) can be tracked to ensure that they are not lost. In case of a retailer sending a Purchase Order to a supplier, if the Purchase Order is “lost” anywhere in the business process, the effect is devastating to both businesses. To the supplier, they do not fulfill the order as they have not received it thereby losing business and damaging the business relationship with their retail client. For the retailer, they have a stock outage and the effects are lost sales, reduced customer service and ultimately lower profits.
In narrowly defined EDI terminology “inbound” and “outbound” refer to the direction of transmission of an EDI document in relation to a particular system, not the direction of merchandise, money or other things represented by the document. For example, an EDI document that tells a warehouse to perform an outbound shipment is an inbound document in relation to the warehouse computer system. It is an outbound document in relation to the manufacturer or dealer that transmitted the document.
One of the main advantages of narrowly defined EDI is its advantage over paper systems. Narrowly defined EDI and other similar technologies save a company money by providing an alternative to or replacing information flows that require a great deal of human interaction and materials such as paper documents, meetings, faxes, email, etc. Even when paper documents are maintained in parallel with EDI exchange, i.e. printed shipping manifests, electronic exchange and the use of data from that exchange reduces the handling costs of sorting, distributing, organizing, and searching paper documents. EDI and similar technologies allow a company to take advantage of the benefits of storing and manipulating data electronically without the cost of manual entry or scanning.
There are a few barriers to adopting electronic data interchange. One of the most significant barriers is the accompanying business process change. Existing business processes built around slow paper handling may not be suited for narrowly defined EDI and would require changes to accommodate automated processing of business documents. For example, a business may receive the bulk of their goods by 1 or 2 day shipping and all of their invoices by mail. The existing process may therefore assume that goods are typically received before the invoice. With narrowly defined EDI, the invoice will typically be sent when the goods ship and will therefore require a process that handles large numbers of invoices whose corresponding goods have not yet been received.
Another significant barrier for using narrowly defined EDI is the cost in time and money in the initial set-up. The preliminary expenses and time that arise from the implementation, customization and training can be costly and therefore may discourage some businesses. The key is to determine what method of integration is right for your company which will determine the cost of implementation. For a business that only receives one P.O. per year from a client, fully integrated EDI may not make economic sense. In this case, businesses may implement inexpensive “rip and read” solutions or use outsourced EDI solutions provided by EDI “Service Bureaus”. For other businesses, the implementation of an integrated EDI solution may be necessary as increase in trading volumes brought on by EDI force them to re-implement their order processing business processes.
The key hindrance to a successful implementation of narrowly defined EDI is the perception many businesses have of the nature of EDI. Many view EDI from the technical perspective that EDI is a data format; it would be more accurate to take the business view that EDI is a system for exchanging business documents with external entities, and integrating the data from those documents into the company's internal systems. Successful implementations of EDI take into account the effect externally generated information will have on their internal systems and validate the business information received. For example, allowing a supplier to update a retailer's Accounts Payables system without appropriate checks and balances would be a recipe for disaster. Businesses new to the implementation of narrowly defined EDI should take pains to avoid such pitfalls.
Increased efficiency and cost savings drive the adoption of narrowly defined EDI for most trading partners. But even if a company would not choose to use EDI on their own, pressures from larger trading partners (called hubs) often force smaller trading partners to use EDI.
To summarize the prior art up to this point, XML is not narrowly defined EDI. XML is a means of doing data interchange in a broader sense, but not EDI narrowly defined by standards, such as, but not limited to, X12, UN/EDIFACT, TRADACOMS, ODETTE, etc. Also, narrowly defined EDI touts as one of its main advantages—no paper. Lastly, narrowly defined EDI documents can be translated in XML tagged schema, and narrowly defined EDI can be encapsulated in XML schema, but narrowly defined EDI is not XML.
Other forms of non-narrowly defined EDI data interchange can include various forms of data capture or Auto ID system, such as, but not limited to, bar codes, radio frequency identification (RFID), magnetic stripe, optical character recognition (OCR), etc.
Bar codes were first introduced in the United States in the late 1960s. Bar code technology allows almost any data to be collected rapidly and with almost perfect accuracy. Bar code technology provides a simple and easy method of data collection by encoding text information that is easily read by many different stationary, and/or inexpensive hand held electronic devices. Bar codes have become the standard method of identification, processing, and management used universally throughout the manufacturing, retail, and distribution industries. While the utilization of this technology has been limited to printed media, similar needs exist for capturing, storing, and interchanging data using a digital medium.
Another form of data interchange is Optical Character Recognition (OCR). This technology has been employed to speed the collection of human readable data, in the form of handwriting, from scanned paper forms. Even though OCR speeds the data collection process, it is still an expensive method due to the error-checking required to insure that correct data has been captured and input. Also, OCR is limited in its ability to be a widely adopted data interchange technology.
Optical character recognition (OCR) was one of the earliest Auto ID technologies used in retail applications since mid-1980. Today, OCR is currently part of resurgence because of improved reading equipment that is much more accurate, and recognizes a wider range of type styles than earlier equipment.
OCR is typically used to read selected areas of text (as opposed to text recognition software that process full pages of text). OCR is both human- and machine-readable and suited for use with account numbers or short data strings.
OCR readers scan the data in much the same way bar code scanners do: either by moving the document past the scanner or moving the scanner over the document. The scan produces a “picture” of the text that is then analyzed for characteristic features. Features are then matched to specific letters or numbers for output.
It should be noted that OCR readers do not work the same way as vision systems do. The equipment for text string scanning is much simpler and less expensive that vision systems or text scanners.
Another OCR technology is magnetic ink character recognition (MICR). MICR like OCR has a narrow range of usefulness as an EDI system that can be widely adopted.
Another OCR technology is intelligent character recognition (ICR). ICR is the intelligent recognition of non-OCR font characters, and hand-printed characters. ICR like OCR and MICR has a narrow range of usefulness as an EDI system (in the broadest definition of EDI) that can be widely adopted.
Wireless devices in the form of cellular phones, PDA's, pager's, etc. have equipped consumers with additional functionality; however barriers have become more complex between such devices and their various operating platforms and software applications. In addition, these devices do not provide for an easy-to-use, two-way interactive means by which to access and interchange data.
To achieve the desired flexibility and speed in capturing, storing, and interchanging data, businesses and consumers continue to deal with increasingly complex integration issues with management information systems.
Some of these issues have recently been solved by leveraging the proven ability of bar codes as an easy, point-of-use method for capturing and exchanging data, where computing devices may share the same data sources seamlessly and easily. More importantly, these methods enable small to medium size companies with electronic commerce capabilities without the need to build infrastructure, or to develop sophisticated middle-ware solutions.
Another form of data interchange, or EDI in its broadest definition that is becoming more prevalent is eXtensible Markup Language (XML). XML is an open standard that is a subset of SGML (Standardized General Markup Language). XML was developed to overcome the shortcomings of HTML (Hypertext Markup Language) which much of the data on the Internet was originally tagged.
Many large businesses have positioned themselves to conduct business online, but due to the costs and complexity associated with electronic commerce, their vendors have not been quick to follow. Given the cost savings benefits of on-line businesses, these companies will be more willing to find new suppliers and trading partners online rather than by traditional means.
During the past decade, acquisitions and mergers have also escalated at a rapid pace as more and more companies posture for a piece of international trade. As economies continue to open, companies will continue to aggressively pursue strategic alliances to capitalize on these opportunities. To date, an overriding consideration in such alliances has been complex conversion and information exchange issues. While the Internet has done much to free the information flow, the compatibility of legacy hardware and software remains paramount.
Even though business has tried to become paperless for the past two decades, paper documents persist, and will for the foreseeable future.
Another limitation of e-Forms is they have been limited to HTML, XML, or PDF formats or a few proprietary formats.
There is therefore an unfilled need for a method and apparatus which overcomes the limitations of narrowly defined EDI, overcomes and uses data interchange technologies such as OCR, bar codes, RFID, and magnetic stripe, and addresses the persistence of paper by embracing it, and solves these and other problems. This invention has as its primary objective fulfillment of this need for electronic data interchange in its broadest definition. The present invention is not, however, to be limited in any way by this discussion.